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(54) Management of event information data with a mobile communication device 



(57) In a system for managing event information da- 
ta with a mobile communication device (1) event entries 
are stored in a database (1 7) and parameterized at least 
with a category, time and (geographical and/or logically) 



location. 

Therefore a list of accessible events can be presented 
to the user of the mobile communication device (1) by 
querying the event database (17). 
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Description 

[0001] The present invention relates to a method for 
managing event information data, to a computer soft- 
ware program product for implementing such a method 
as well as to a mobile communication device having an 
event managing module. 

[0002] Different systems are known from the prior art 
filtering events according to the user's profile and the 
current date, e.g. by using personal agents. Further- 
more many static lists or events are e.g. available in the 
Internet. Furtheron, there are systems that allow to send 
event notifications and reminders to specific user 
groups. Finally, calendar systems allow to enter events, 
to organise events as well as to retrieve events. 
[0003] However, ail known systems suffer of a plural- 
ity of different drawbacks. E.g. neither the location as- 
pect of an event nor the time aspect for travelling to the 
location of an event is considered. 
[0004] In view of these disadvantages it is the object 
of the present invention to propose a technique allowing 
a correlated time and position management of event in- 
formation. 

[0005] This object is achieved by means of the fea- 
tures of the independent claims. The dependent claims 
develop furtherthe central idea of the present invention. 
[0006] According to a first aspect of the present inven- 
tion therefore a method for managing event information 
data is proposed. The current time in the position of a 
mobile communication device is inquired. Using the cur- 
rent time in position information to generate a template 
an event source such as e.g. an event database is que- 
ried. The event source contains events entries param- 
eterized by the category, time and location. Finally a list 
of accessible events is presented on the mobile com- 
munication device, wherein the list of accessible events 
is generated by means of the query. 
[0007] Optionally profile information on the user of the 
mobile communication device can be part of the tem- 
plate used for the query of the event source. 
[0008] At least for apart of the accessible events a 
transportation information for possible ways to get from 
the current position of the mobile communication device 
to an event location can be calculated and presented on 
the mobile communication device. 
[0009] The list of accessible events can be presented 
dynamically. In other words, the list of accessible events 
can be updated to generate a list of remaining accessi- 
ble events each time the user of the mobile communi- 
cation device accepts an event of the list. When gener- 
ating the updated version of the event list, the parame- 
ters (time, location, etc.) of events already accepted by 
the user are taken into account. 
[0010] Accessible events accepted by the user of the 
mobile communication device can be automatically 
transferred as entries to an electronic calendar file. 
[0011] The user of the mobile communication device 
can create events for the list of accessible events and/ 



or for the event source (e.g. event database). 
[0012] This can e.g. be achieved by creating events 
manually by customising generic events proposed by 
the mobile communication device. 
s [0013] A learning mode be provided in which the mo- 
bile communication device learns event preferences of 
the user by evaluating the interaction with the user. 
[001 4] The user can pre-configure standing orders for 
events such that corresponding events are automatical- 
ly ty selected when retrieved in the event source. 

[0015] The event entries of the event source can be 
generated automatically by searching a network such 
as e.g. the Internet. 

[0016] According to a further aspect of the present in- 

*5 vention a computer software program product is pro- 
posed implementing a method as said above when run 
on a mobile computing device. 
[0017] According to a still further aspect of the present 
invention a mobile communication device with an event 

20 managing module is proposed. The event managing 
module comprises means for determining the actual 
time and the current geographical position of the mobile 
communication device. Furthermore means for query- 
ing an internal and/or external event source are present. 

25 The event source contains event entries parameterized 
by category, time and location. A query can be per- 
formed on the basis of a template, containing at least 
the current time and geographical position of the mobile 
communication device. Finally means for presenting a 

30 list of accessible events output by the querying means 
are provided. 

[0018] The template used by the querying means can 
furthermore comprise profile information of the user of 
the mobile communication device. 
35 [0019] Furthermore the mobile communication device 
can comprise a navigation module for calculating and 
presenting possible ways to get from the current position 
of the mobile communication device to the location of 
an event. 

40 [0020] Computing means can update the list of acces- 
sible events dynamically to generate a list of remaining 
accessible events each time the user of the mobile com- 
munication device accepts a proposed event from the 
list. 

45 [0021] Finally means for automatically transferring 
accessible events accepted by the user of the mobile 
communication device as entries to an electronic calen- 
dar file can be present. 

[0022] Further advantages, features and objects of 
50 the present invention will become evident for the man 
skilled in the art when the readings of the following de- 
tailed description of an embodiment taken in conjunction 
with the figures of the enclosed drawings. 

55 Figure 1 shows a schematic representation of a sys- 
tem of implementing the present invention, 

Figure 2 shows schematically the adaptation of the 
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events, and 

Figure 3 shows schematically a possible distribu- 
tion structure for implementing the present inven- 
tion. 

[0023] With reference to Figure 1 at first a system for 
implementing the present invention will be explained. 
[0024] To this objective at first some externs and im- 
pressions will be explained. An "event" in the sense of 
the present invention is a social gathering or activity 
which usually has a certain start time, a time duration 
and therefore also an end time. In contrast to meetings 
of another gathering of a number of people is important, 
but a purpose of the invent, which requires certain 
sources (e.g. a film projector, a certain location, etc.) 
which are available only at certain places. Therefore an 
event happens at a certain location. A user has to get 
to this location from the current location which usually 
takes some time. Furthermore resources like transpor- 
tation means maybe necessary. Events are attended by 
a certain number of people. Events can be described as 
a structure like: 

Event purpose, location, date, start time, duration, 
attendees. 

[0025] A "template" is an event specification which 
consists of a number of specified attributes. An example 
of a template is: 

"film performance", Hedelfinger Str. 61 + 5 km, 
24.10.00, 18:00 GMT 

[0026] A "query" is a task to select a synchronously, 

i.e. while the user is waiting for the result. 

[0027] A "standing order" is a task to select events to 

inform the user about the occorns of these events as 

synchronously, i.e. while the user is disconnected to the 

system. 

[0028] Now, the components of a system for imple- 
menting the present invention will be explained for sev- 
erance to Figure 1 . 

[0029] A query management module 12 manages the 
queries and standing orders of users. In case of a query, 
the query management module receives this task from 
a presentation adaptation and interaction module (PI- 
AM) 6, asks the event gathering module 9 for events 
fitting into the template of the task, and sends these 
events to a selection and ordering module 1 0. After hav- 
ing received the results from the selection and ordering 
module 1 0, the query management module 1 2 forwards 
them to the PIAM 6 for display on a mobile communica- 
tion's device. To allow some interaction steps, the query 
management module 12 stores all data concerning the 
query in order to react to the user's interactions. There 
are two possible interaction steps. If a user accepts 
events proposed by the system, these events are en- 
tered into the calendar module 5 and the query is re- 
processed by sending again the events to the selection 
and ordering module 1 0 etc. As there are now more time 
restrictions, the result returned from the selection and 



ordering module 1 0 to the query management module 
10 might differ from the first step. If a user removes 
(waives) an event in the calendar module 5, the query 
management module 12 is notified and the query is re- 
5 processed to generate again new results returned from 
the selection and ordering module 1 0 to the query man- 
agement module 12. 

[0030] In the case of a standing order the query man- 
agement module 12 receives this task from the PIAM 6. 
10 it asks the event gathering module 9 to inform the query 
management module 1 2 in case of the occurrence of an 
event fitting into the template. The processing of this 
task is then stopped, but all data concerning the task is 
stored in the query management module 12. As soon 

15 as the event gathering module 9 notifies the query man- 
agement 1 2 on the occurrence of corresponding events, 
the query management module 12 sends the events to 
the selection and ordering module 1 0, receiving in turn 
the result which is a list of accessible events. The query 

20 management module 1 2 asks the presentation adapta- 
tion and interaction module 6 (PIAM) to inform the user 
on the result using the means the user selected. 
[0031] Finally the query management module 12 for- 
wards view selection information from the PIAM 6 to the 

25 context management module 7 when appropriate. 
[0032] In the following the function of the event gath- 
ering module 9 will be explained. This component gath- 
ers events and delivers sets of events that match a given 
template. There are several possibilities for the event 

30 gathering module 9 to gather events. One is to search 
appropriate information sources when events are need- 
ed, e.g. by using a search engine in the Internet 3 by 
consulting event web pages in the Internet 3. Another 
possibility is to subscribe to appropriate event sources, 

55 such that the event gathering module 9 is informed on 
the occurrence of new events. In order to react queries 
quickly, the event gathering module 9 can proactively 
search information sources (Internet 3 etc.) even with- 
out already knowing tasks. Thereto it can employ an 

40 own event database 1 7 to store events. In order to allow 
third parties to directly insert events manually, the event 
gathering module 9 can offer a manual input interface 
14 to do so. 

[0033] In case of a query the event gathering module 
45 9 receives a template from the query management mod- 
ule 12 and answers it by returning a list of accessible 
events that fit into the template. In case of a standing 
order the event gathering module 9 receives a template 
from the query management module 1 2. As soon as the 
50 event gathering module 9 finds an event that fits into the 
template, it informs the query management module 12 
by returning a list of events that fit into the template. 
[0034] To fulfil its task the event gathering module 9 
can access a location database 8 in order to determine 
55 the location of and the distance to retrieved events. After 
having accessed the location database 8, every location 
entry in an event is extended by the geographic position 
of the location. Therefore the geographic position can 
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e.g. be stored along with the event entry in the event 
database 17. 

[0035] The location database 8 is able to associate 
positions to symbolic (logic) location data as provided 
in the events. Such an association can be e.g.: 

"Gloria 1" = 34.00078N, 4.8901 W 134.3 Meter). 
[0036] The first string denotes the symbolic (logic) 
name. The second part contains the graphic position e. 
g. in the WGS 84 format. Symbolic (logic) names can 
include names a location is known under ("Munchener 
Hofbrauhaus"), an address ("Hedelfingerstr. 61") and 
other references to locations. Symbolic (logic) names 
are delivered by the event gathering module 9. The lo- 
cation database 8 answers such a request with the cor- 
responding geographic position. 
[0037] Now the function and operation of the selection 
ordering module (SOM) 10 will be explained. This com- 
ponent gets a set of events from the query management 
module 12 and selects and orders events aeon to a set 
of attributes. It answers to the query management mod- 
ule 12 by returning an ordered list of events. The set of 
attributes is requested of the context management mod- 
ule 7. It consists of an open set of data like: 

• User preferences like 

event categories 
key words 

- names of preferred participants (and their 
roles) 

- preferred locations 



35 



40 



• open time/location slots. 

[0038] In order to determine the time distance of and 
the way to events, the selection and ordering module 10 
can access the navigation module 11. It requests these 
data by delivering the a start in target location of possible 
transportation means. 

[0039] A description of the way and an estimation of 
the time needed in returned from the navigation module 
7. 

[0040] Navigation module 11 is connected to a posi- 
tion determination means such as e.g. a GPS. The po- 
sition determination means 1 5 can be furthermore con- 45 
nected to the query management module 12. The nav- 
igation module 11 can compute path to go from location 
to another one, resulting in a description of the way and 
the time necessary given a set of possible transportation 
means. so 
[0041] The Context Management Module 7 gathers 
and stores context data and delivers them to the SOM 
1 0 in order to configure the selection and ordering proc- 
ess and to the PI AM 6 in order to configure the presen- 
tation adaptation and the interaction process. Context 55 
data might include: 

• the location of the user 



• data and time at the location of the user 

• the temperature at the location of the user 

• personal user data like his/her schedule 

• the history of his/her service usage 

5 • the actual condition of the network the user con- 
nects to 

• the actual condition of the user device 

• the user profile (e.g. age, gender, nationality, and 
user preferences) 

10 • the abilities of the user device 

• the social situation the user currently experiences. 

[0042] Parts of these data are collected from the CM 

5. 

1* [0043] When in "learning mode" the CMM 7 tries to 
gather user profile information automatically by exam- 
ining the interactions of the user with the service (see G 
in Figure 1), and , when possible, also by watching other 
Internet usage of this user outside the service. This in- 
20 formation is again stored inside the CMM 7. 

[0044] To allow users to use different sets of context 
data (e.g. to have different preferences according to the 
mode (business trip or holiday journey)), context data 
sets can be organised into different "views". The user is 
25 able to select these views using the PIAM 6 (which in- 
forms the QMM 12, which finally informs the CMM 7 
about the currently selected view). When delivering con- 
text information, the currently selected view is used. 
[0045] The Presentation Adaptation & Interaction 
Module PIAM 6 presents the results of queries and 
standing order to a user. This presentation is adapted 
according to context data like: 



• Type of the used device 

• the actual condition of the network 

• and so on 

[0046] Additionally, the PIAM 6 allows the user to do 
the following things: 

• enter a new request 

The user can specify all relevant attributes and 
modes of presentation (e.g. concerning sorting etc.) 
This results in a query that is sent to the QMM 12. 

• enter a new standing order 

The user can specify all relevant attributes. 
This results in a query that is sent to the QMM12. 

• modify a standing order 

This is done by requesting a standing order 
from the QMM 12 and let the user modify it. The 
standing order is then resent to the QMM 12. 

• watch the results of requests or standing orders 

• accept an event of an event list 

In case of acceptance, the event is entered into 
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the CM 5, then the QMM 12 is notified in order to 
get a new result that considers the new time/loca- 
tion restrictions that result from that choice. 

• select a view 

♦ select notification means 

[0047] Additionally, the PIAM 6 is able to send notifi- 
cations to offline users when the system detected an 
event that fits into a standing order. 
[0048] The calendar module 5 presents a calendar- 
like presentation to the user Events the user has ac- 
cepted are entered into this calendar. In case of e.g. a 
change of mind or when exploring alternatives, a user 
can also waive accepted events in the calendar. In this 
case, the Query Management Module 12 is informed. 
To integrate into an existing office environment, the cal- 
endar module can be an existing product (e.g. Microsoft 
Outlook) as long as other programs can enter events 
and as long as other programs can sense the removal 
of events in the calendar. 

[0049] Additionally, the calendar is one source of in- 
formation for the context management system. 

Flows inside the system 

A query is processed 

[0050] The user starts a query process at the PIAM 6. 
The user enters a query at the PIAM 6, thus specifying 
e.g. the date, time, and location of the events to get. The 
PIAM 6 produces a template out of that and sends it, 
together with other data (e.g. presentation options, and 
the view to use) to the QMM 12. The QMM 12 creates 
a query entry and stores it. Afterwards, it sends the tem- 
plate to the EGM 9. The EGM 9 gathers events that fit 
into that template, e.g. by using its internal database. It 
also uses the LD 8 to determine whether an event fits 
into the template. Finally, it extends the events that fit 
into the template with the geographic positions gathered 
from the LD 8. This set of events is returned back to the 
QMM 12, where it is stored in the query entry. The QMM 
12 sends this set to the SOM 10. The SOM 10 applies 
its selection and ordering algorithm using data gathered 
from the CM M 7. To determine, in which time events can 
be reached, the SOM 10 uses the NM 11 which also 
delivers a description of the ways to reach the event. 
This description also extends the events. The SOM 10 
then returns an ordered list of events back to the QMM 
12. The QMM 12 sends this list to the PIAM 6, where it 
is presented to the user by applying the presentation ad- 
aptation mechanisms using context data from CMM 7. 
[0051 ] The user is now able to accept events from that 
list or remove events in the calendar. 
[0052] After having finished the query, the user stops 
the query process. 



8 

The user accepts an event 

[0053] If the user accepts an event in the PIAM 6, the 
event is sent to the CM 5 where it is entered into the 

5 calendar of that user. Additionally, the PIAM 6 sends the 
acceptance notification to the QMM 12, which in turn 
starts the selection and ordering process by sending the 
SOM 1 0 the set of event received before from the EGM 
9, but where the accepted event has been removed. As 

10 the accepted event further restricts the time/location 
availability of the user, another list of events might result 
from this process (the SOM 10 will know of this restric- 
tion as it receives these context data from the CMM 7, 
which, in turn, queries the CM 5). As above, the new list 

15 of events is presented to the user, and the user again 
can accept an event. 

The user waives an event 

20 [0054] Events in the CM 5 (i.e. accepted events) can 
be waived by the user at any time. In this case the event 
is removed from the user's calendar by the CM 5. If no 
query is currently processed, no further steps are taken. 
If currently a query is processed and the waived event 

25 is one that originated from that query, this event is sent 
to the QMM 12 and the whole query process is re-start- 
ed. The only difference is that the event is again added 
to the event set stored at the QMM 1 2. If currently a que- 
ry is processed and the waived events does not origi- 

30 nate from that query process, the complete query proc- 
ess is started again by the QMM 12, i.e. also the EGM 
9 is asked for events that fit into the query template. 

A standing order is entered 

35 

[0055] The user specifies a standing order at the PI- 
AM 6 in a similar way as he/she specifies a query with 
the one difference that also the communication means 
is specified that shall be used to inform the user about 
40 the occurrence of a corresponding event. The PIAM 6 
then sends this standing order to the QMM 12, where a 
standing order entry is generated. Finally, the QMM 12 
sends the corresponding template to the EGM 9. 

45 A standing order is processed 

[0056] If the EGM 9 finds one or more events that fit 
to the template of the standing order (using the LD 8 in 
the same way as with queries), it sends these events to 

50 the QMM 1 2, specifying the standing order they belong 
to. The QMM 12 then starts the selection and ordering 
process in the same way as in the query process. When 
the QMM 12 sends the event list to the EGM 9, it also 
adds the communications means specification selected 

55 by the user. Finally, the user is notified about the event 
list using the selected communications means by the 
EGM 9. The user is then able to connect to the system 
and to interact in the same way as during a query (i.e. 
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accepting and waiving events). 

[0057] In the following data structures for the system 

will be explained. 

[0058] One data structure is the event and event tem- 
plate, respectively, as they determine which kinds of 5 
events can be found. As described above, events mainly 
consist of 6 elements, namely: 

• event purpose 

• location 10 

• date 

• start time 

• duration 

• list of attendees 

15 

where the event purpose might be described with a 
standardised language (ontology). The location can be 
described either by a geographic position or a symbolic 
name that can be replaced by the LD 8 with a geographic 
position. 20 
[0059] Event templates have to offer possibilities to 
specify these elements in a fuzzy way. Per element, 
these possibilities include, apart from let an element un- 
specified (denoted by an "*"): 

25 

Event purpose 

[0060] Here the problem is that we may have general 
and more specialised categories like "performance" - 
"opera". Therefore we need something like a tree of cat- 30 
egories, so an event can be described by higher-level 
categories. Additionally, some purposes should be de- 
scribed by several categories, therefore we need a list 
of categories describing an event. 

[0061] It is obvious that we need parameters for this 35 
element, for e.g. specifying a certain film (like "Casa- 
blanca"). 

Location 

40 

[0062] This element contains the geographical posi- 
tion of the event. 

[0063] Additionally, this element may contain an 
"threshold*" attribute that specified the range of x me- 
ters around this data for events that fit into that template. 

Date 

[0064] This element contains the date of the event. 
[0065] Additionally, this element may contain an 50 
"thresholds" attribute that specified the range of x days 
around this data for events that fit into that template. 

Start time 

55 

[0066] This element contains the start time of events. 
If have to make sure that also the time zone of this time 
is encoded in order to prevent miscalculations. 



[0067] Additionally, this element may contain an 
"threshold*" attribute that specified the range of x sec- 
onds around this data for events that fit into that tem- 
plate. 

Duration 

[0068] This element contains a duration e.g. in min- 
utes. 

[0069] Additionally, this element may contain an 
"threshold*" attribute that specified the range of x sec- 
onds around this data for events that fit into that tem- 
plate. 

List of attendees 

[0070] This element contains references to persons. 
Ordering 

[0071 ] Each of the elements above might additionally 
contain an "ordering: n" attribute that denotes that this 
element shall also be used for order the event set. The 
parameter n of this attributes denotes the rank of the 
ordering element. 

Examples of event templates 

[0072] What to do now and here? 

(event purpose=*; 

location=ORDER:1,34.7894N.85993W.374m,thresh- 
old: 1 0000m; 
date= 19.10.00; 

start=ORDER:2,13:41 MET threshold: 3600sec; 
duration=ORDER:3, *; 
list of attendees = *) 

[0073] Planning of a day out in Paris 

(event purpose =*; 

location=ORDER:1 .17.7894N.81 .993W.374m,thresh- 
old: 10000m; //was "Paris, Boulevard St. Germain" 
date= 15.11.00; 

start=ORDER:2,8:00 MET, threshold: 36000sec; 
duration=ORDER:3,*; 
list of attendees=*) 
[0074] A true fan 

(event purpose = Music Performance of "The Jellyba- 
bies"; 

location = ORDER: 1.34.7894N. 85.993W.374m,thresh- 

old: 50000m; 

date=*; 

start=*; 

duration = *; 

list of attendees = *) 

Specification of queries and standing orders 

[0075] The easiest way to implement this aspect is 
certainly to offer the user an interface where he/she can 
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specify every single element with all the given possibil- 
ities. Unfortunately, this would require the knowledge of 
how to specify these things. Therefore, this possibility is 
only suited for expert users. Additionally, especially mo- 
bile devices like mobile phone normally do offer only 5 
very restricted input possibilities (as they rarefy include 
a keyboard and feature only small displays). 
[0076] Normal users or users using this type of devic- 
es can use a restricted interface that allow to choose 
only of a few possibilities. One of these possibilities is io 
the "what to do now and here" mode, where the system 
generates a template as described above using the cur- 
rent time and location taken from the CMM (which, in 
turn, might have sensed these information at the user's 
device). 15 
[0077] The easiest way to interact with the system is 
to allow active suggestions based on implicitly gathered 
profiles as then the user does not have to further specify 
queries or preferences. Another possibility to help users 
specifying queries and standing order is to use default 20 
values also stored in the CMM. 

Gathering events: 

[0078] Events can be entered directly via manual in- 25 
put. In this case all relevant information can be gathered 
easily using an appropriate form. 
[0079] Events can be also gathered by searching ap- 
propriate information sources, e.g. web pages, e-mails 
(if this is appropriate under privacy aspects), and data- 30 
bases. Especially in the web, there are many pages that 
offer event data in a human-readable form, e.g. http:// 
www.stuttgart.de/sixcms/list.php37page id =25. There 
are also some databases in the Internet, e.g. httg://www. 
lift-online.com/cgi/setkalender.pl where event data can 35 
be queried automatically. As there is no standard for of- 
fering such data, and as the audience for event data is 
normally a human one, most information sources fea- 
ture an own event data format, often suited for human 
use. Therefore, an architecture that wants to use these 40 
information sources has to cope with the different for- 
mats, which might be also the subject of frequent, un- 
announced changes. The EGM 9 has then simply to 
translate the event data format of the information sourc- 
es to the one used in the system. 45 
[0080] In the near future, such events might be offered 
on sources like web servers as XML documents. In this 
case, the EGM has to know and to understand the cor- 
responding DTDs. 

[0081] Events are stored into an event database 17 so 
inside or outside of the EGM 9, e.g. in XML form, in order 
to quickly react on queries by the QMM 12. 

Getting events from the EGM 

55 

[0082] To return a set of events that fit into a given 
event template, the EGM 1 2 has to consider all elements 
of an event template. An element qualifies for being in- 



cluded in the event set, all of its elements have to qualify. 
An element qualifies if it is unspecified ("*"). Whether a 
specified element qualifies, depends on the element: 

Event purpose 

[0083] This element qualifies if the specified category 
is a predecessor in one of the category hierarchies of 
the event, and if the parameter, if specified, are equal. 

Location 

[0084] This element qualifies if the geographical loca- 
tion of the event (as determined by the LD 8) lies in the 
range specified by the event template. 

Date 

[0085] This element qualifies if the date of the event 
lies in the range specified by the event template. 

Start time 

[0086] This element qualifies if the date of the event 
lies in the range specified by the event template. 

Duration 

[0087] This element qualifies if the date of the event 
lies in the range specified by the event template. 

List of attendees 

[0088] This element qualifies if the list of persons 
specified in the event template are contained in the list 
of attendees of the event. 

Selection and Ordering Algorithm 

[0089] The selection and ordering algorithm is a two- 
stage process. In the first stage events out of the incom- 
ing event set are selected according to some criteria re- 
ceived from the CMM determined by a view selected by 
the user. One of these criteria is the calendar of the us- 
ers: only events are selected that do not collide with ex- 
isting entries. Another criteria is the time needed to 
reach the location of an event. Computed by the NM 11 , 
this time need is considered when events are selected 
that fit into the time range of the event template. 
[0090] In the second stage, the events are ordered ac- 
cording to the ordering criteria. These criteria are spec- 
ified in the event templates. 

Presentation adaptation 

[0091 ] The presentation is adapted inside the PI AM 6 
towards the user in relation to a whole n umber of factors. 
The presentation process consists of at least three stag- 
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es (see Figure 2) 

[0092] The first stage is the "data adaptation" which 
adapts the presentation according to the characteristics 
of the data (i.e. the events) itself. If an event is e.g. near- 
by, just the event description and the location of the 
event might be displayed, if an event is not nearby, but 
in the same city, additionally the public transport data 
(time tables, ways to a station) is displayed, etc. These 
adaptation can be realised e.g. by using a rule mecha- 
nism that is able to specify things like "if (event.location 
= "nearby") then show (event.desription .event.loca- 
tion)" or "if (event.location = "intown") then show (event, 
description, event, location, event, transportation, time- 
tables)". 

[0093] The second stage is the "user adaptation" 
which adapts the presentation in relation to the user. 
This includes adjustments according to the explicit set- 
tings by the user, his/her preferences that have been 
learned by the system, etc. 

[0094] The third stage is the "device adaptation" 
which adapts the presentation according to the charac- 
teristics of the actual user device and the data connec- 
tion to that device. This adaptation includes adjustments 
to things like the screen size, the colour abilities, the 
needed presentation format (e.g. HTML or WML), the 
actual bandwidth, and the condition of the network. 
[0095] The components of the system could be dis- 
tributed as depicted in Figure 3. The PI AM 6 component 
can be decomposed into a system-side PIAM module 
6, and a user-device-side client program 4. The latter 
might consist simply of a web or a WAP browser. Alter- 
natively, it might consist of a special client program that 
handles interaction of the user with the system. The CM 
5 might reside on the user device; in this case it might 
consist of an existing calendar program (like Microsoft 
Outlook). 

[0096] The overall system can be realised as a serv- 
ice of a multi-access service portal. 
[0097] The EGM 9 gathering process can be realised 
using translator and adaptor components that translate 
events from the format at the source into the format that 
is used inside the system, and that encapsulate the que- 
rying process of the event source, respectively. It can 
be expected that events can be accessed in the web in 
an XML-based format in the future. 
[0098] The EGM 9 can employ a SQL database to 
store the events gathered. The Event templates can 
then be realised by SQL statements that are used to be 
executed in the EGM database. 
[0099] The CM 5 can be located either on the user's 
device, in the system, or on another computer in a con- 
nected network. The CM 5 can be e.g. realised using 
Microsoft Outlook using its COM interface on the user's 
device. 



Claims 

1. Method for managing event information data, 
the method comprising the following steps: 

5 

inquiring the current time (16) and the position 
(15) of a mobile communication device (1), 
using the current time (16) and position (1 5) in- 
formation for a template to query (1 2) an event 
io source (9), the event source (9) containing 

event entries parameterized by their category, 
time and location, and 

presenting (6) a list of accesible events on the 
mobile communication device (1), wherein the 
15 list of accessible events is generated by means 

of the query (12). 

2. Method according to claim 1 , 
characterized in that 

20 furthermore profile information of the user of the 
mobile communication device (1 ) is part of the tem- 
plate to query (12) the event source (9). 

3. Method according to claim 1 or 2, 
25 characterized in that 

at least for a part of the accessible events a trans- 
portation information for possible ways to get from 
the current position of the mobile communications 
device (1 ) to an event location is calculated (11) and 
30 presented. 

4. Method according to anyone of the preceding 
claims, 

characterized in that 

35 the list of accessible events is presented (6) dynam- 
ically, i.e. the list of accessible events is updated to 
generate a list of remaining accessible events each 
time the user of the mobile communication device 
(1) accepts an event 

40 

5. Method according to anyone of the preceding 
claims, 

characterized in that 

accessible events accepted by the user of the mo- 
45 bile communication device (1) are automatically 
transferred as entries to an electronic calendar file 
(5). 

6. Method according to anyone of the preceding 
50 claims, 

characterized in that 

the user of the mobile communication device (1) 
can create events for the list of accessible events 
and/or for the event source (9). 

55 

7. Method according to claim 6, 
characterized in that 

the user can create (14) events by customizing 
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manually generic events proposed by the mobile 
communication device (1). 

8. Method according to anyone of the preceding 
claims, 

characterized by 

a learning mode in which the mobile communication 
device (1) learns event preferences of the user by 
evaluating the interaction with the user. 

9. Method according to anyone of the preceding 
claims, 

characterized in that 

the user can preconfigure standing orders for 
events such that corresponding events are auto- 
matically selected when retrieved in the event 
source (9). 

10. Method according to anyone of the preceding 
claims, 

characterized in that 

the event entries of the event source (9) are gener- 
ated automatically by searching a network (3). 

11 . Computer software program product, 
characterized in that 

it implements a method according to anyone of the 
preceding claims when run on a mobile computing 
device (1). 

12. Mobile communication device having an event 
managing module, 

the event managing module (1, 2) comprising: 

- means (15,16) for determining the actual time 
and the current geographical position of the 
mobile communication device (1), 

means for querying (1 2) an internal and/or ex- 
ternal event source (9) containing event entries 
parameterized by their category, time and loca- 
tion, wherein the querying is performed on the 
basis of a template containing at least the cur- 
rent time and geographical position of the mo- 
bile communication device (1), and 

- means for presenting (6) a list of accessible 
events being output by the querying means 
(12). 

13. Mobile communication device according to claim 
12, 

characterized in that 

the template used by the querying means (12) fur- 
thermore comprises profile information of the user 
of the mobile communication device (1). 

14. Mobile communication device according to claim 12 
or 13, 

characterized in that 
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20 



it furthermore comprises a navigation module (11) 
for calculating and presenting possible ways to get 
from the current position of the mobile communica- 
tion device (1) to the location of an event. 

15. Mobile communication device according to anyone 
of claims 12 to 14, 

characterized by 

a computing means (6) for updating the list of ac- 
cessible events dynamically to generate a list of re- 
maining accessible events each time the user of the 
mobile communication device (1) accepts an event. 

16. Mobile communication device according to anyone 
of claims 12 to 15, 

characterized by 

means (12) for automatically transferring accessi- 
ble events accepted by the user of the mobile com- 
munication device as entries to an electronic calen- 
dar file (5). 
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